We had a meeting with LV about their AI assistant and they require showing an image of the VI connector. The same image LV shows in a VI's context help. So, we require supporting images.

Another feature they want is the ability to add buttons at the top-right of a message respond. The scenario UX showed was generating multiple VI descriptions and having '<' and '>' buttons to see them one at time. There will also be a button or a dropdown to allow the user to ask the AI to try again with some options from the dropdown. Alice is working on the UX design. I will ask her to send me a link so you can see it.

I'll add images to the list of example content. With this design the message content is entirely up to the client application so supporting images wouldn't take any additional work. However at some point (outside the scope of this spec) we'll want to discuss how we plan to do that: if we want to use Nimble's rich text viewer we would need to enhance its capabilities.

I'll be interested to see those new designs. If they're within the body of the message then we can support it with the proposed approach. If they're separate content that are positioned by the message then we may want to add some new slots or attributes. We could tackle that in a follow up update to this document.

I prefer to have a dedicated component based on the pros. I do agree it is better to have the toolbar in a single place so it can be updated in a single place.

I think we may have different answers in the short term and medium/long term. My current leaning for the first pass is to just focus on the message and conversation and not create a toolbar in Spright. That gives the dev team time to get up to speed and the UX team time to solidify the toolbar UX more.

Then once we know more in a few weeks/months if we find we still want a toolbar it's easy to add it.

Is there a reason we went for status over appearance was the concern we might want block / ghost / outline versions or something? Or I guess we could have appearance bubble (sms-style) vs threaded (slack/discord-style), etc. in the future. Edit: actually I don't think that appearance would be per message but instead per conversation.

The name status doesn't feel quite right, feel like status is a transitory thing like "in progress", "delayed", etc. Like the status of a message could be loading or is-typing or failed-to-send or something.

Did we already think about type or mode? Other options didn't come to mind yet.

Any preference of incoming/outgoing vs inbound/outbound? Seems like the latter is used more for tech / messaging (email inbox, sms, etc). Looks like the terms used in lightning as well (didn't search more broadly): https://www.lightningdesignsystem.com/components/chat/